Covers the seven follow-ups recorded on handover from the dark-theme
series: theme preference, non-production dark default, GraphiQL and
Mermaid theme binding, token migration for legacy pages, data viewer
tone, and schema visualizer dark support.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Scrollbars, native form controls and their popups, autofill highlights
and the canvas behind overscroll are painted by the browser, not by CSS,
and stay light in dark mode unless color-scheme says otherwise. Declare
it alongside each palette so the two can never drift apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The open navigation item and the active sort/filter icons painted a fixed
indigo in both themes. Measured against the surface each actually sits
on, it cleared neither: 3.7:1 in light and 4.3:1 in dark, against the
4.5:1 AA needs for 16px text.

An --active token takes the dark end of the ramp in light and the light
end in dark, reaching 6.3:1 and 6.2:1. The icon call sites keep their
exact light appearance, since indigo-700 is what the light token
resolves to; only the sidebar shifts, and only because it was the worse
of the two failures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Working on the dark theme has meant editing a class onto the document by
hand, so nobody used it long enough to find what is still wrong with it.
A development stack now starts dark, and the account menu carries a
switch out of it, marked alpha.

The theme is off unless a deployment opts in through
INFRAHUB_EXPERIMENTAL_DARK_THEME, which only development/docker-compose
passes through. A deployment brought up from the root compose file has
no way to reach it, which is deliberate while the theme is alpha: the
gate hides the switch entirely rather than offering a light-only one,
since match-system would otherwise walk a dark-desktop user straight
into it.

Dark is the default when enabled, rather than the operating system's
appearance, because the point is that everyone working on a development
stack sees the theme being worked on — deriving it from the desktop
would give it only to the engineers already running one.

A choice made here is remembered per browser and survives the flag being
turned off: disabling a feature is an operator's decision about a
deployment and must not reach through and delete what users picked. An
inline script applies the remembered theme before the first frame, so a
reload does not flash light and then snap to dark once config arrives.

Documentation screenshots are pinned to light, or a regeneration run on
a development stack would quietly turn every published image dark.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Base's "color cleanup" reworked three surfaces this branch had already
tokenized. Took base's version in all three: each is the more thorough fix,
and the mechanical `bg-gray-*` → `bg-content-strong` swaps here were only ever
the minimum that made them theme-aware.

- Token display: base replaces the ad-hoc classes with the shared `inputStyle`,
  so the box matches surrounding inputs, and adds `size="md"` to the copy
  button. Keeping this branch's version would have silently dropped both.
- Drop target: base tokenizes the border as well (`border-ring bg-highlight`),
  where this branch had left `border-custom-blue-500` fixed.
- Disabled list: base drops the background entirely for `opacity-60`, which is
  theme-agnostic by construction rather than by token lookup.

Verified base's versions resolve before taking them: `--color-ring` and the
`--highlight` gradient both exist, `inputStyle` is imported, and
`CopyToClipboard` accepts `size`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Same class of miss as the date picker: react-toastify's default "light"
theme paints a hardcoded white card, invisible to the bg-white sweep
because the colour lives in a vendored stylesheet. Unlike the date
picker it themes through its own custom properties, so re-pointing the
light theme's two surface variables at our tokens is the whole fix —
the tokens flip under `.dark`, and the toast follows with no `theme`
prop and no JSX. The close button is the one colour outside its
variable system (hardcoded near-black), overridden alongside.

Semantic icon colours (success/error/info/warning) are deliberately
untouched — semantic palettes are tracked separately.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…hite

The prefix header fades its overflowing fields out at the right edge by
painting a white gradient over them — a white smear in dark mode. No
token can replace the white: the panel behind is a per-theme gradient,
not a flat colour.

A CSS mask fades the content itself to transparent instead, so whatever
the panel paints shows through exactly, in any theme, with the overlay
element gone entirely. Verified in both themes on the live page.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

A pass over every gradient stop and fixed-palette background the earlier
sweeps missed, verified live rather than by grep alone:

- Diff-summary skeleton pulsed light gray in dark; the shared Skeleton
  already shimmers with a translucent tint that works in both themes, so
  it now just uses it.
- The disabled list input had a second disabled site the base branch's
  cleanup did not reach; same fix as the first (opacity, no fixed
  background).
- The IPAM available-prefix separator dots move to the border token,
  whose light value is the identical gray they hardcoded.
- The resolved-thread card dropped its `to-gray-200` — probing the exact
  shipped classes showed it has been dead in both themes: the Card
  paints `background-image: var(--card)` directly, which Tailwind's
  gradient-stop utilities never touch. The "Resolved" checkbox already
  carries the state, so the class is removed rather than replaced with
  an equally dead token version. Restoring a working resolved tint is a
  design decision left for its own change.

Reviewed and deliberately left: the colour-picker trigger's palette
gradient (an affordance, not a surface), the always-dark tooltip and
data-viewer families and everything rendered inside them, the diff
expander strips (the diff palette is tracked separately), and the
timeframe pill's fixed dark chip (pre-existing design, legible in both).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

GraphiQL's dark theme hangs off two HSL triplets with hue 219, a
blue-navy that clashed with the warm near-black shell around it. Its
every surface is derived from those two variables, so re-pointing base
and neutral at stone-900 and stone-200 retunes the whole sandbox — the
container now computes to rgb(28,25,23), byte-identical to the app's
dark content surface.

The triplets are duplicated from the theme as bare HSL components
because GraphiQL composes them itself via hsl(var(...)) and cannot read
oklch tokens. The selector list mirrors GraphiQL's own dark block so
its portalled dialogs and tooltips retune with the main container.
Light is untouched: the override only matches body.graphiql-dark, and
GraphiQL's light base is already the same white as the app's content
token.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test: assert the current tree row by its new selected class

94cde56 replaced the hardcoded bg-neutral-100 highlight on the current
tree row with semantic tokens for dark theme, but the E2E assertions still
pinned the old literal class. The row is highlighted correctly; only the
assertions were stale.

That one change is why four jobs went red: the same assertion appears
eight times across both suites, sharded into E2E-testing-playwright plus
the foundation, sites_a and sites_b pytest shards.

Assert bg-selected alone rather than the full token set, so a later shadow
or hover tweak does not break these again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix: stop leaking react-aria render-prop keys as class names

composeAriaClassName invokes its tailwind callback with react-aria's
render-props object, but TreeItem and ListBox both named that parameter
resolvedClassName and forwarded it into cn(). cn is clsx-compatible, so an
object argument emits its truthy keys as class names -- every tree row and
list box carried a literal "hasAction hasChildItems level selectionMode
selectionBehavior state id defaultClassName".

Neither component uses any render prop, so pass the styles as a plain
string. composeAriaClassName already merges the consumer's className after
them, which is why the leak was cosmetic rather than a styling bug.

Predates the dark-theme work; introduced in 33da87f. Correct callers
destructure what they need, e.g. ({ isPressed }) in button.tsx.

Add a regression test asserting no render-prop key reaches the row's class
list, and that a consumer class still survives. Verified red before the
fix, green after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test: cover the class-name leak for ListBox too, not just TreeItem

Both components had the same defect and the same fix, but only TreeItem
had a regression test. Add the ListBox equivalent, and move the file to
shared/components/aria/ since it now covers className composition for two
unrelated components rather than anything tree-specific.

ListBox leaked a different set of keys (layout, orientation, state,
defaultClassName) because react-aria's render props differ per component,
so each list is asserted separately.

Both leak tests were verified red against the unfixed components. The four
pass-through tests pass in both states, which is the point: the fix
removes the leaked keys and changes nothing else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

The pre-paint script can only replay a theme this browser has resolved once
before, so a first-time visitor arrives with no class at all. Applying the
resolved theme from a passive effect let that first commit paint in the wrong
palette and then snap to the right one.

A layout effect runs before the browser paints the commit, which closes the
window entirely.

The end-to-end theme assertions were sampling the class once, immediately after
a visibility wait, and could observe the same window. They retry now — except
the two that run at domcontentloaded, which must keep sampling once: retrying
there would also accept a class arriving later from React, which is exactly the
regression they exist to catch.

Two spec corrections found while checking the above:

The token-discipline command could never fail. Git's ERE does not implement \b
on every platform, and where it does not, the whole pattern matches nothing --
so "expect no output" passed while the check was seeing no files at all. Where
\b does work, it reported five standing false positives, because the legitimate
dark:bg-white/N overlays match a bare literal just as well as a fixed palette
does. Switched to -P with a lookbehind that excludes the variant.

T041 claimed a plugin-array stability test that does not exist, and cannot
usefully exist: the React Compiler memoises that array whether or not the
useMemo is hand-written, so an assertion on it passes identically with the memo
deleted. Recorded the property as held by compilation rather than shipping a
test that cannot fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The visualizer deliberately does no theme detection of its own, so it renders
whatever the embedder resolves. Passing the resolved theme is the whole
integration.

Pins the submodule at the squash-merge commit on main rather than at the branch
commit this branch had been carrying. The two are not the same object: the
upstream PR was squash-merged, so neither the old pin nor the branch tip is an
ancestor of main, and the old pin would break every checkout once the branch is
deleted. It was also three commits behind, missing the upstream review fixes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>